home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000160_news@columbia.edu _Fri Dec 29 13:42:37 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by monire.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA23770
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 29 Dec 2000 13:42:37 -0500 (EST)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA28314
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Dec 2000 13:42:37 -0500 (EST)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id NAA08997
  10.     for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Dec 2000 13:25:54 -0500 (EST)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: Igor Sobrado <sobrado@string1.ciencias.uniovi.es>
  13. Subject: Re: Converting struct tm to time_t
  14. Date: 29 Dec 2000 18:24:36 GMT
  15. Organization: Universidad de Oviedo
  16. Message-ID: <92ikt4$q09$1@news01.si.uniovi.es>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In comp.protocols.kermit.misc Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  20. >   How to convert a struct tm (which already is expressed in GMT) to
  21. >   a time_t which expresses the clock time in GMT (not local time) in
  22. >   a way that is reliable (works in any timezone and takes daylight
  23. >   savings into account) and is portable to as many UNIX platforms as
  24. >   possible (and how to do the same things on the platforms to which
  25. >   this portability does not extend)?  The answer (as noted previously)
  26. >   is not mktime(), since it presumes its argument is in local time,
  27. >   not GMT.
  28.  
  29. I am not sure about portabilityFrom news@columbia.edu  Fri Dec 29 13:42:37 2000
  30. Return-Path: <news@columbia.edu>
  31. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  32.     by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA03482
  33.     for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 29 Dec 2000 13:42:37 -0500 (EST)
  34. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  35.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA28311
  36.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Dec 2000 13:42:36 -0500 (EST)
  37. Received: (from news@localhost)
  38.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id NAA08908
  39.     for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Dec 2000 13:21:26 -0500 (EST)
  40. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  41. From: Russ Allbery <rra@stanford.edu>
  42. Subject: Re: Converting struct tm to time_t
  43. Date: 29 Dec 2000 10:17:43 -0800
  44. Organization: The Eyrie
  45. Message-ID: <yllmszt7lk.fsf@windlord.stanford.edu>
  46. To: kermit.misc@columbia.edu
  47.  
  48. In comp.unix.programmer, Frank da Cruz <fdc@watsun.cc.columbia.edu> writes:
  49.  
  50. > As you say, your code does presume a few things about what time_t is:
  51.  
  52. >  . An integer (in the mathematical sense), unsigned.
  53. >  . The number of seconds since 1 Jan 1970 0:00:00.
  54.  
  55. > If that is always true, fine.
  56.  
  57. My code doesn't assume it's unsigned; it just won't generate negative
  58. time_t values.  It works fine on systems with a signed time_t (basically
  59. all of them).
  60.  
  61. I believe that both of these assumptions are required by POSIX; they're
  62. certainly true on every UNIX system that I've ever seen.  I believe there
  63. are some Windows systems that didn't use an integral time_t, however.
  64.  
  65. > Anyway, I suppose it's worth a shot.  In the meantime, too bad whoever
  66. > thought of mktime() didn't make it do just one thing (in the UNIX
  67. > spirit), instead of two things at once, without allowing those things to
  68. > be done separately.
  69.  
  70. I believe that mktime is an ANSI/ISO C function.  ISO C has no concept in
  71. the language of time zones, only of local time.
  72.  
  73. > Another solution that had occurred to me was to compare the localtime()
  74. > and gmtime() results for the same clock time, figure out the GMT/UTC
  75. > offset, and deduct it to the target struct tm before passing it to
  76. > mktime(), but gmtime() and localtime() are not among the most portable
  77. > of UNIX APIs,
  78.  
  79. Really?  I've never seen a Unix system without them, and was under the
  80. impression that they were introduced in the early 1980s.
  81.  
  82. > plus I don't know how consistent their semantics are across platforms,
  83. > e.g. if you give them a seconds or minutes field greater than 60 or less
  84. > than 0, etc.
  85.  
  86. Neither gmtime() nor localtime() take something that has a seconds or
  87. minutes field, so I assume that you're talking about mktime().  mktime()'s
  88. normalization of out-of-range values is a requirement of its definition,
  89. which I believe is in ANSI C.
  90.  
  91. -- 
  92. Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>
  93.                    | mktime(3C)
  94.                                                     V
  95.                                     +-------- time_t (UTC+offset)
  96.                                     |               |
  97.                                     |               | gmtime(3C)
  98.                                     |               V
  99.                     time_offset <---+       struct tm (UTC+offset)
  100.                          |          |               |
  101.                          V          |               | mktime(3C)
  102.                  (used to change    |               V
  103.                 MDTM time (UTC) to  +---- time_t (UTC+offset+offset)
  104.                 local time before
  105.               convert it to time_t)
  106.  
  107. Hope this helps (and hope this works!),
  108. Igor.
  109.  
  110. -- 
  111. Igor Sobrado, UK34436 - sobrado@acm.org
  112.